Thanks for the PR, didn't know mk64 had an interest in fast64 :) I know nothing about mk64 so I can provide some insights on integrating with fast64 but not on the game stuff itself

I help to the decomp by document the game here is just minimal feature so only the model but later add actor spawn and waypoint can be great but I don't know to much blender to know how I can add this and later export this

also other games like OoT have readmes with some documentation, like
https://github.com/Fast-64/fast64/blob/main/fast64_internal/oot/README.md

Ideally you'd create one as fast64_internal/mk64/README.md too describing the features / getting started

Just a quick thought. SM64 likely has some features that aren't relevant to mk64.

Is there a possibibility of an mk64 mode that disables stuff like geo layouts?

Just a quick thought. SM64 likely has some features that aren't relevant to mk64.

Is there a possibibility of an mk64 mode that disables stuff like geo layouts?

when you create another categories/game it disable other thing of SM64 and OOT so it's fine

@Dragorn421 also on blender MK64 onglets never disappear you know why ?

@Dragorn421 also on blender MK64 onglets never disappear you know why ?

I'll look into it, I assumed from the code that'd work

bump on #316 (comment) (version prop) btw

I test on windows and it work and I fix two little mistake so normally all it's good, if upgrade_changed_props are fine also

Here is my quick review, I'd like to point out that you should probably be using snake case more for variable and function names, sticking to naming conventions would be nice :) I really would like you to consider the organization aspect i mentioned.

when I make the PR all function and name have been in camel case so I don't if it change in lastest commit

sorry I'm having a hard time understanding your sentance, english is also not my first language so no judgment from me but please re-phrase

a majority of variable and function are in camel case so I put also all new function and variable in camel case

yes but ideally we'd follow the blender standard/recommendation, so pep8 with a few naming conventions, at the end of the day this is mostly fine but moving foward its best to go with something more conventional, that's what seems to be the agreed upon idea anyways although it's not very inforced.
https://docs.blender.org/api/current/info_best_practice.html

I know python base of naming convention but use snake case now feel weird because everything else are in camel case so I think a specialise PR to fix naming convention issue will be better then update some code with it but not all

Commiting my suggestion was a bad idea

If you want to you can get the suggestion commited, I verified the code is up to date this time and edited it, it's a minor thing so I will leave this approved

I still not understand how https://github.com/Fast-64/fast64/pull/316/files/f323083a82cc12d2a9314e99d7b858b6f9fba4bf#diff-90ba2d4286547c68f1de376ff45f43ea1c4d2bd499349eb51914f06fd1706084 result into f1f197d

but now it's fixe